More Complex Scenarios
Directory server can of course contain data in more complex structures than assumed in Basic Scenario. When it comes to more complex scenario, DN input as well as other options in configuration come handy. Let us have a look on some more complex configuration use cases.
Sync particular DN
It is pretty common that users meant to be synced to IceWarp Server are located in a special organizational unit (OU) on the domain controller (DC) or directory server. If that is the case, DN of the location must be filled in DN input in configuration. IceWarp Server will synchronize all object included in the OU (and other nested OUs) matching other configuration settings. If objects should be pulled from more OUs on the same level in the directory hierarchy DN must be set that it would allow reading both of those OUs. Usually that means that more than just desired OUs is sent to IceWarp, if that is the case filter can be used to filter out unwanted objects. However setting filter might not be necessary as missing or unsuitable mail attribute can do the same job. Please, check out example configuration in the Case 1 in Sync Accounts from Multiple Email Domains article below for further information.
Example Configuration
Example describes a configuration for setup where the DC domain is example.local, IceWarp Server domain is example.com and users/groups are located in the Artificial Set 2 OU. IceWarp Server will log on to DC using the userPrincipalName attribute while users will use their sAMAccountName to log on to IceWarp Server services:
Figure. Domain configuration example.
Sync One Account to Multiple IceWarp Server Domains
Synchronization mechanism can handle uncommon use cases where same object is required to be synced to multiple IceWarp Server domains (usually two of them). This is easy to achieve as configuration of each domain would fit into scenarios described in the AD Domain Different from IceWarp Server Domain and/or Email Domain of AD Accounts Is Different from IceWarp Server Domain.
Excluding Accounts Disabled on AD from Synchronization
IceWarp Server does not reflect disabling of an account in ActiveDirectory as even disabled account is returned in basic LDAP search query response. That is obvious as disabled account basically remains the same - only disabled flag bit of the userAccountControl attribute is toggled. Synchronization mechanism itself does not parse or understand this attribute. It means that disabling an account in AD will not disable the account on the IceWarp Server side. However, a filter can be effectively used to exclude disabled accounts from LDAP search query response. Accounts present in IceWarp Server that cease to be returned from AD (due to filter update), will be deleted (mail storage is preserved by default, this behavior is controlled by the ALLDATADELETION node in the config/syncad.dat file). In order to query individual bits of the userAccountControl attribute we can bitmask it - there are special matching rules to do that (to learn more about these see https://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx). In our particular case, we want to bitmask userAccountControl on two which would be written in the filter query syntax as: userAccountControl:1.2.840.113556.1.4.803:=2.
Of course, this must be negated as we want to exclude all disabled entities that match this statement.
In practice, filtering out disabled accounts can be written as follows:
Unfortunately, some Linux platforms may consider filter with id matching rule as invalid, therefore it will not work. You will have to find a suitable solution.
Sync Accounts from Multiple Email Domains
Synchronization configuration offers possibility to use "*" to accept any object that have mail related attribute defined regardless the domain part value. This is handy when there are various email domains used inside the organization, but everyone should have public email address in single IceWarp Server domain. Such use case has usually 2 typical scenarios:
-
All objects are located in the same container like one OU so scope of DN limits results by itself. In this case, simple filter can work (as DN is already restrictive enough). However, it may be required to synchronize only several email domains instead of all of them. This would require limiting LDAP search query results with a more complex filter based on mail attribute value.
-
It may be required to sync object from multiple containers so DN scope itself is not enough to limit search query results. In this case query response usually contains many objects that are not relevant or desired for sync. The only option left to remove unwanted objects from response is more precise query defined in filter input.
Shortening response by filter positively affects performance too as sync mechanism does not have to handle objects with incorrect mail attribute value, also size of AD synchronization logs gets reduced.
Examples:
Case 1:
Single OU (ou=mail users.dc=corp.dc=example.dc=local) contains user accounts with email address from different domains (corp.example.local.example.com, example.net), but we want to have objects using only 1 of the domains (example.com) in mail attribute.
DN: ou=mail users.dc=corp.dc=example.dc=local
AD: (&(objectClass=inetOrgPerson)(mail=*@example.com))
Case 2:
Multiple OUs (ou=icewarp.dc=example.dc=local) should serve as a source of objects to sync. User accounts with mail attributes with domain part from particular domains (example.com or example.net) are desired.
DN: dc=example.dc=local
AD: (&(objectClass=Person)((mail=*@example.com)(mail=*@example.net)))
